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ABSTRACT 



A method for providing synchronous message transfer 
is provided in an asynchronous operating environment 
in which conversational status can be established be- 
tween communicating endpoints. The operating envi- 
ronment includes a transaction processing system hav- 
ing a plurality of terminals, a data communication com- 
ponent (DCC), and a transaction processor (XP) which 
exchanges message data with DCC for transmission to 
selected terminals. The method steps comprise ascer- 
taining at the DCC whether a transaction initiated by a 
message is synchronous or asynchronous; passing the 
ascertained transaction from the DCC to the XP for 
generating a response; and processing the resp>onscs to 
synchronous transactions in progress, while retaining 
the responses to asynchronous transactions until the 
synchronous responses are completed. A stored vari- 
^le data object for each terminal includes a field for 
indicating when a synchronous transaction is in 
progress and a field for identifying the input message 
initiating the synchronous transaction. Messages re- 
ceived from a terminal are inspected to determine their 
destination processes. When a message destined for a 
synchronous process is received from a terminal, entry 
is made into the synchronous field of the terminal's 
associated data object and an identification associated 
with the message is entered into the object's message ID 
field. When the synchronous flag is set in the terminal's 
associated data object, transaction responses directed to 
the terminal are inspected to ascertain which constitutes 
the synchronous response. All asynchronous responses 
for the terminal are buffered until the synchronous 
response is identified and processed for transmission to 
the terminal. 

5 Claims, 3 Drawing Sheets 
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METHOD OF PROVIDING SYNCHRONOUS 
MESSAGE EXCHANGE IN AN ASYCHRONOUS 
OPERATING ENVIRONMENT 

5 

BACKGROUND OF THE INVENTION 

This invention relates to asynchronously-operating 
. systems in which synchronous processes can be selec- 
tively invoked. More particularly, the invention relates 
to an asynchronous transaction processing system 
which also supports the selective invocation of syn- 
chronous transaction processes. 

Transaction processing characteristically involves a 
system in which a central transaction processor (XP) is 
connected, on a time sharing basis, to a multiplicity of 
user terminals which access the transaction processor 
for the purpose of conducting transactions Relatedly, a 
transaction is an exchange between a terminal and the 
transaction processor that accomplishes a particular 
action or result For example* in banking transaction ^ 
systems, an automatic teller (user terminal) may be used 
to effect the withdrawal of funds from a customer's 
account and the updating of the customer's account 
balance to reflect the withdrawal. Transaction process- 
ing is covered in detail in Chapter 1 8 of the work by C. 
J. Date entitled "AN INTRODUCTION TO DATA- 
BASE SYSTEMS. VOLUME ONE," Addison-Wes- 
ley, 1986. 

A transaction necessarily involves an application 
process in the transaction processor which is dispatched 30 
to conduct a transaction in response to input data pro- 
vided by a message from a user. As with any other 
computer process, an application process involved in a 
transaction consists of receiving the input, processing 
the input, and generating an output signifying the trans- 35 
action response to the input. In an on-line multi-terminal 
transaction processing system* a system user engages in 
a transaction by inputting data into the system directly 
from one of the terminals cotmectedt through a commu- 
nication node, to the transaction processor. The re- 40 
sponse is transmitted from the processor back to the 
point of origin of the input data, 

In a synchronous environment, after inputting trans- 
action data, a terminal is "held** by the application pro- 
gram conducting the transaction while the transaction 43 
processing is performed, and is released when the re- 
sponse is transmitted to the terminal. A terminal is ''re- 
leased*' by transmission to the terminal of a release 
message containing a code which unlocks the terminal 
keyboard at the terminal and restores the terminal to an 50 
unused ready condition, thereby permitting the user to 
enter other messages. In an asynchronous environment, 
the terminal may be released before the response to the 
originally-initiated transaction is received. If the trans- 
action requires synchronism, preferably the terminal is 55 
not released until the response is generated; then, the 
terminal release and the transaction response are trans- 
mitted simultaneously. 

Frequently, a synchronous transaction involves a 
conversational mode of operation in which a sequence 60 
of alternating entries and responses between the termi- 
nal user and the transaction processor takes place. In a 
conversational transaction, a terminal should be held by 
the executing application program until all of the en- 
try/response iterations are completed. When released. 65 
the terminal is free to initiate another transaction. 

If the terminal is engaged in an asynchronous transac- 
tion, the application program can release it prior to 
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input processing and response generation. When re- 
leased, a terminal can initiate another transaction, await 
the response of the current transaction, or view re- 
sponses from other transactions which are queued for 
output to the terminal. Thus, asynchronism in the trans- 
action processing context means essentially that, once a 
terminal is used to initiate a transaction, it is discon- 
nected from the transaction executing process. While 
the transaction processor is provided with a means for 
retitming the response to the terminal, other response 
data from various sources may also be generated for 
transmission to the terminal in a nonpredictablc se- 
quence. 

It is known that an on-tine transaction processing 
system can operate to selectively provide a terminal 
user with either synchronous or asynchronous connec- 
tion to an application program. Such selection is nor- 
mally an artifact of initiating a transaction supported by 
one of two or more independent subsystems in the trans- 
action processor. For example, a transaction processor 
can include a pair of database management systems 
(DBMS) such as the customer information control sys- 
tem (CICS) and information management system 
(IMS), both software products available from IBM, 
Armonk, N.Y. As is known, the transactional comple- 
ment of the IMS includes both synchronous and asyn- 
chronous transactions, while the CICS supports only 
synchronous transactions. 

Synchronous transactions are normally used for high 
priority, short-duration processes. For example, a termi- 
nal user may wish to retrieve or update a particular 
record in a file. 

Asynchronous transactions are best suited for low 
priority, long-duration process where the retention of 
the terminal until response is delivered would result in 
incfTicicnt operation. An example of this type is a re- 
quest that may retrieve a large niunber of records for 
inspection, select some subset based on user specified 
criteria^ sort the subset in a user specified sequence, 
route the list to a device for printing, and respond to the 
requestor when the list had completed printing. 

In a transaction processing system supporting both 
synchronous and asynchronous transaction processing, 
it is desirable to permit a user to initiate concurrent 
execution of synchronous and asynchronous processes. 
This will permit a user to initiate one or more long-term 
(asynchronous) processes and. while awaiting a result 
from the processes, initiate synchronous processes in 
order to make more effective use of on-line time. 

The implementation of a transaction facility com- 
pounding synchronism and asynchronism most fre- 
quently takes place in the context of a transaction pro- 
cessor controlled by an asynchronous operating system. 
The multiple virtual storage (MVS) system available 
from IBM is the principal example of such an operating 
system. MVS is a multiprogramming operating system 
which can support the concurrent execution of a vari- 
able number of transaction processes. When a message 
is received from a terminal, it is edited as necessary and 
the required transaction fWiction is identified. At the 
same time, the terminal is released to perform more 
input operations or to receive output transmissions from 
the transaction processor. As input from the terminal is 
processed and responses generated, control of the ter- 
minal may be reacquired for transmission of the re- 
sponses. Such a mode of operation is necessary to sup- 
port the asynchronous IMS functions, message switch- 
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ing, bulk data transfer, printer spooling, and other such concurrently with the synchronous transaction by buff- 

asynchronoiis applications. ering the responses to executing asynchronous pro- 

For interactive synchronous operations, the desired cesses generated for a given terminal until a concurrent 
effect is to initiate the transaction, have it processed, synchronous process initiated by the terminal has com- 
and receive the response before continuing with the 5 pleted. The invention is founded on the critical observa- 
next operation. In an asynchronous operating environ- tion that concurrency among synchronous and asyn- 
ment, it is possible for a user to enter a synchronous chronous processes can be maintained by relating re- 
request and then, before the response is generatedt re- sponses to specific inputs and scheduling process of 
ccive a message from a different, asynchronous process responses rather than inputs. This permits a system to 
such as a message switch from another terminal or the 10 concurrently execute synchronous and asynchronous 
reply from a prior asynchronous transaction. This has transactions for the same terminal without requiring 
the appearance of a wrong answer to a request and may intelligence at the terminal or a particular level of 
be confusing to an inexperienced system user. Another ^ ^his is accomplished by embodiment of 
disadvantage of the asynchronous method of system invenUon in a method for estabUshing and raaintain- 
operation occurs when an asynchronous transaction 15 ^ conversational status among communicating end 
requires a long time to respond. An mipaticnt operator . ^ ^ ^ transaction processing system that includes a 
may enter a request and, while awaitmg a tardy reply, of terminals, a data communication component 
reenter it one or more tmics. Smce the termmal is re- ^ ^ transaction processor (XP) which ex- 
leased in the ^synchronous envuomncnt. a s«iuence of ^ ^ transaction data in the form of messages with 
substantially identical transactions is conducted which 20 . * ^ ^ ^ i * j * • i -n. 

. - J ^ . . . A.„;„« ^ the DCC for transmission to selected tennmals. The 

can lead to improper data update and confusion of a j ^ r _* ■ ^ *u 

*u J -1 « o/int-A- method compounds the steps of ascertaining, at the 

user as the identical replies are displayed m a corre- »^ ^ • ^ u 

nd* ff resnonse seauence DCC, whether a transaction mitiated by a message 

'^ol^ns to the problem of providing for synchro- generated at ^terminal and forwarded to the XP 

nous transaction processing in an asynchronous operat- 25 ^OMgh the DCC is synchronous or asynchronous, 

ing environment exist in the prior art. For example, U.S. Pas^ing the ascertamed transaction from the DCC to the 

Pat. No. 4,410.940 of Carlson ct al. describes a method XP for generation of a response, and processing the 

permitting cooperating sequential processes to pass responses to synchronous transacUons in progress while 

control among themselves as they progress to termina- buffering the responses to asynchronous transactions 

tion. Such passage of control is founded upon a prior 30 until the synchronous responses are extinguished, 

knownledge of process input and caimot accommodate Alternatively, the invention is embodied as a method 

the random arrival order of transactions. for synchronous transaction processing in an asynchro* 

Another method of imposing synchronism on an nously operated transaction processing system in which 

essentially asynchronous operating system is known as a plurality of terminals exchange messages with a trans- 

"bracket protocol." A bracket is treated by an asyn- 35 action processor (XP) through a dau communication 

chronous operating system as defining an uninterrupta- component (DCC). the processor including plural ap- 

ble unit of work consisting of one or more input/re- plication processes which support terminal-initiated 

sponae exchanges between the transaction processor transactions by generating responses to message-borne 

and a terminal. The first input of the first exchange in transaction codes. In the first step of the method, it is 

the unit includes a header that indicates "begin 40 ascertained at the DCC whether a message from a ter- 

bracket," and the fmal output indicates "end bracket." minal will initiate a transaction which is synchronous or 

Essentially, acceptance of the "begin bracket" locks the asynchronous. Next, when a transaction is determined 

communication path between the terminal and the synchronous, execution takes place against a data 

transaction processor and imposes a DEMAND/RE- object associated with the terminal to provide an indica- 

SPONSE protocol to a transaction until the end bracket 45 ^Jq^ synchronous transaction; then, the ascer- 

occurs. In this regard, the bracket control is also a form transactions are passed to the XP from the DCC 

of input management in that it prevents the execution of generation of responses. In reaction to each response 

any other transaction processes until the final bracket generated for the terminal by the XP, the data object is 

releases the lock. Further, smce the bracket method is ^^^ed to ascertain whether a synchronous transac- 

tcnninal-oncnted, it require cither that extra mtelh- $0 jjo^ has been initiated and, if a synchronous transaction 

gence be provided to a termmal or that a user have the ^ ^^^^ contemplates passing 

level of skill necessary to use the meAod. ^ only a response included in the synchronous transaction 

In view of the mcreasmg mixture of synchronous and ^ ^ transmission to the terminal and buffer- 

asynchronous processes m transaction processors w i^v^v. ««« • *v * • i 

whTch include asynchronous operating systems, there is 55 "Jf ^ o^»^^^ ^«P0"^ transmission to the termmal 

an obvious need for a technique that provides an effec- completion of the sjmchronous^^ Other- 

tive means for supporting synchronous transactions ^^onsc is passed to the DCC for transmission 

without preventing concurrent completion of executing to the terminal. ^ ^. . ^. , 

asynchronous transactions. It is evident that the self- It is therefore an object of this mvention to provide 

scheduling and bracket techniques of the prior art are 60 ^ot establishment and mamtenance of a synchronous 

not equipped to meet this need. transaction between a terminal and a transaction proces- 
sor which does not prevent the completion of concur- 

SUMMARY OF THE INVENTION rently-executing asynchronous transactions involving 

The present invention fully satisfies the stated need of the terminal and the processor, 

supponing synchronous transaction processing in an 65 This object and other objects and attendant advan- 

asynchronously-operated transaction processing envi- tages of the invention will become more apparent when 

ronment without surrendering the opportunity to per- the detailed description of the invention is read with 

mit completion of executing asynchronous transactions reference to the figures. 
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FIG. 2 supports both synchronous and asynchronous 

BRIEF DESCRIPTION OF THE DRAWINGS transaction processing in an asynchronously-operating 

FIG. 1 is an illustration of a multi*tenninal transac- system. In this regard, the transaction processor of FIG. 

tion processing system including a transaction proces- 1 is understood to be programmed with an asynchro- 

sor» a transaction processing subsystem, a data commu- 5 nous operating system such as the IBM MVS system, 

nication component, and a representative one of a plu- The operating system of the XP 10 is indicated by 28 in 

rality of terminals. FIG. 2. A programmed transaction processing subsys- 

FIG. 2 is a block diagram illustrating the prior art tcm (XPS) 29, such as the CICS, operates under the 

interconnection of a pair of database management sys- control of the operating system 28. Apphcation pro- 

tems with a plurality of transaction application pro- 10 grams (APP) 30 and 32 are conventionally linked to the 

grams in the transaction processor of FIG. I. operating system 28. It is postulated that the application 

FIG. 3 is a block diagram of an execution module programs 30 and 32 provide processing support for 

embodying the machine and process structures suitable synchronous transactions carried out against a database 

for implementing a transaction determination step of the (DB) 33 through a database management system 

invention. 15 (DBMS) 34, which is associated with the XPS 29. In 

FIG. 4 is a block diagram of the execution module of FIG. 2, the XP 10 can also contain a second pro- 

FIG. 3 which illustrates the machine and process struc- grammed transaction processing subsystem 35, such as 

lures and interconnections necessary for processing the IMS. The operating system 28 of the XP 10 also 

transaction responses according to the method of the controls operation of the XPS 35. Another set of syn- 

invention. 20 chronous and asynchronous transactions arc supported 

FIG. 5 is a flow chart Qlustrating the procedures by application processes 40 and 42, which reference the 

executed in the practice of the method of the invention. database 33 by way of a DBMS 44 associated with the 

r^tr -TOE TSDctTCDDcri ^ Stated abovc. the IMS does support syn- 

DESCRIPTION OF THE PREFERRED chronous and asynchronous transactions executed 

EMBODIMENT against a database such as the DB 33. 

Referring fust to FIG. 1, a transaction processing In the prior art, several techniques are used with 

system is shown comprising at least a transaction pro- varying degrees of success, to permit synchronous and 

cessor PCP) 10 (which can comprise a programmed asynchronous transactions to intermix. Most require 

computer), a transaction processing subsystem (XPS) either appLcation program or terminal operator in- 

11, a data communications component (DCC) 12, and a 30 volvemcnt to produce the desired result, 

plurality of terminals, two of which are indicated as 14 As is known, a transaction processing subsystem such 

and 16. As is conventional with multi-termina] systems, as CICS XPS 29 or IMS XPS 35 may use a data commu- 

the DCC 12 comprises a progranuned communication nications access method (DCAM) 49 such as IBM's 

support entity that manages transmission of data be- ACFA^AM which supports the estabUshment of logi- 

tween the XP 10 and the terminals. Physical data trans* 33 cal connections between a terminal and a transaction 

mission between the DCC and the terminal can be pro- processing subsystem under control of the terminal 

vided by any number of communication protocols in- user. Thus, synchronous transactions can be directed to 

eluding IBM's System Network Architecture (SNA) CICS while asynchronous transactions could be di- 

and is not directly related to the invention being de- rected to IMS under terminal use control 

scribed. 40 Thus, when a synchronous transaction is to be en* 

Data communications between the terminal 14 and tered, the user establishes connection to the XPS 29 and 
the XP 10 are for the purpose of permitting the user of the transactions arc processed in a synchronous manner, 
the terminal 14 to conduct transaction pft>cessing using When an asynchronous process is to be performed, the 
the resources of the XP 10 through the data entry and user disconnects from the XPS 29 and connects to the 
output facilities of the terminal 14. Typically, data entry 45 XPS 35 and enters the transaction(s). While these pro- 
is supported by a keyboard 22, while output is provided cesses complete, the user may return to XPS 29 and 
on a display device such as the CRT screen 24. perform other synchronous processes until some later 

The user of the terminal initiates, or "enters," a trans- time when connection is reestablished by the user with 

action by sending a message having the format indi- XPS 35 to interrogate the system as to the status of the 

cated by 26. The message 26 includes a transaction code 50 asynchronous processes and retrieve the responses of 

(XCODE) which indicates the transaction process re- those completed. 

quested and the data which is to be acted upon by that Another example of a technique used by a synchro- 
process. The transaction code identifies to the XP 10 nous transaction processing subsystem to provide asyn- 
which application program is to process the message. chronous transactions is to perform a series of synchro- 

Thc input message is sent by the terminal 14, received 35 nous operations that simulate the function of an asyn- 

by the DCC 12, and* after determining the destination chronous operation. Using this technique, a transaction 

and transaction characteristics, is passed to the XPS 11 is entered by the user at the terminal 14 which schedules 

for processing. a synchronous application 30. The application 30 initi- 

When the transaction process is completed, the XPS ates a second transaction T2 which causes the schedul- 

11 responds to the "entered" transaction by an output 60 ing of another synchronous application 32 and responds 

message (a "response") to the DCC 12 for transmission with a message to the terminal 14 indicating work in 

to the originating terminal 14. process (WIPI), thus completing the initial synchronous 

Thus described, the system of FIG. 1 forms the appli- transaction Tl. 

cation environment in which the invention is intended The application program 32 processes the transaction 

to be practiced. FIG. 2 illustrates a prior art structure 65 T2 and produces a response R2 for the application pro- 

which is understood to constitute operating systems, gram 30. The response R2 is passed to the application 

application, and service entities conventionally entered program 30 and is saved by the application program 30, 

into the XP 10 as software programs. The structure of thus completing a second synchronous transaction T2. 
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At some later time the user at terminal 14 enters a 
subsequent transaction T3 interrogating the status of the 
prior transaction. The application program 30 retrieves 
the response saved from the prior transaction T2 and 
responds to the terminal with a message R3 indicating S 
the result of transaction T2, thus completing the fmal 
synchronous transaction T3. Thus, when connected to a 
synchronous transaction processing environment, an 
operator may achieve the function of an asynchronous 
transaction, which is to complete a long running pro- 10 
cess without restricting the use of the terminal for other 
work during the process, by utilizing a sequence of 
three synchronous transactions (for example, Tl, T3, 
and T3). 

Conversely, in an asynchronous transaction process- IS 
ing environment, a synchronous result may be achieved 
when desired using a technique which involves cooper- 
ation in the application program. Using this technique, a 
transaction T4 is entered from a terminal 14 and is de- 
termined to require the application program 40, which 20 
performs an asynchronous process. Thus, after schedul- 
ing the application, the terminal 14 is released to per- 
form other work. At this time the user enters transac- 
tion TS from the terminal 14. This transaction is deter- 
mined to utilize the application program 42 which per- 23 
forms a synchronous process. Thus the terminal is held 
awaiting a response from the application. 

This process could work with no application involve- 
ment as long as the synchronous application program 42 
completes prior to the asynchronous application pro- 30 
gram 40. However, there is no way to ensure this in a 
multi-tasking environment. Thus, some process must be 
included to identify the response as the one for which 
the terminal is waiting. This can be done by an applica- 
tion convention indicating that the response is synchro- 35 
nous or by the recognition by the XPS 35 that the appli- 
cation is synchronous. While this technique works well 
in a single system environment where recovery/restart 
is no concern, it does not provide the necessary control 
where multiple systems are involved or where a system 40 
failure is recovered and expected to continue in a rela- 
tively transparent manner. 

To provide for synchronous interactive operation in 
an asynchronously-operating environment, the method 
of the invention is practiced in the form of an executable 45 
process module illustrated in FIGS. 3 and 4 and denoted 
as a data communication component (DCC) 50. The 
DCC is functionally positioned between the network 
and the transaction processing system (XP) 10. Its pur- 
pose is to establish and maintain conversational sutus 50 
between system end points such as the terminal 14 and 
the XP 10 so that a synchronous transaction can be 
conducted through the terminal 14 without being inter- 
rupted by asynchronously-occurring responses from the 
XP 10 or other communicating end points of the system. 55 
This is accomplished without the use of brackets or 
interprocess scheduling and permits other transactions 
already initiated from the terminal 14 prior to the syn- 
chronous transaction to execute while conversational 
status is being maintained. 60 

To provide for synchronous interactive operation, 
transactions in the form of messages received from 
terminals such as the terminal 14 are examined to ascer- 
tain whether they are synchronous or asynchronous. 
This ascertaining step can be understood with reference 65 
to the diagram of FIG. 3. When a message is received 
from the terminal 14 by the DCC 50, it is placed in a 
temporary processing storage location 52. The identifi- 
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cation of the source terminal 14 is used to access a vari- 
able data object denoted as a commimication terminal 
block (CTB) 56. The CTB 56 is a conventional control 
block which is used by the DCC 50 to hold control 
information pertinent to the status of the terminal 14. In 
this regard, each connected terminal of the network has 
associated with it a unique communication terminal 
block. In addition to all data necessary to maintain com- 
munication status with the terminal 14, the CTB 56 
contains four fields pertinent to the functioning of this 
invention. These are: 

the terminal identifier (TID) 58 which contains the 
name by which the terminal represented by this control 
block is known to the system; 

the ^plication synchronous process flag (APSN- 
FLAQ) 59 which is used to indicate whether the appli- 
cation has requested the continuation of a synchronous 
operation after response. This is used if a multiple inter- 
change or "conversation" is required to complete a 
transactional process; 

the message identifier (MID) 60 contains a value that 
is maintained unique for the life of a message. This is 
accomplished by maintaining an 8-byte field, the first 
four bytes of which arc set to the value of the time of 
day clock when the system is initiated and thus are 
always unique for the life of the machine since this 
clock is never reset. The remaining four bytes arc set to 
0 at initialization and are thereafter incremented by 1 on 
the receipt of each the message; and 

the message synchronous indicator flag (SYNC- 
FLAG) 62 used to indicate whether a message has cur- 
rently scheduled a synchronous application or not. 

The transaction code (XCODE) field 63 is passed to 
a message routing routine (ROUT) 64 where the char- 
acteristics which were specified for the transaction are 
analyzed to determine if the message is to be processed 
by a synchronous or an asynchronous application pro- 
gram and the SYNC-FLAG 62 in the CTB 56 is set 
accordingly. 

A message prefix builder routine (PI^ 66 is then 
given control to build a header or prefix for the mes- 
sage. This header includes a number of control fields, 
two of which are used in the implementation of the 
invention being described. One of these is a message 
source identifier field (SID) 84 which identifies the 
terminal from which the message originated. This is 
obtained by copying the TID 58 from the CTB 56 into 
the message header. The other is the message identifier 
(MID) 82 which is a copy of the MID field 60 from the 
CTB 56 after it has been incremented and restored in 
the CTB. 

After the message prefix has been built, it, along with 
the message 68, is passed to the transaction processor 
(XP) 10 for scheduling of the required application pro- 
gram and processing of the message. The DCC 50 then 
interrogates the SYNC-FLAG 62 field in the CTB 56 to 
determine if the message in process was synchronous or 
asynchronous. If the message was synchronous, no 
more input processing need be done until the response is 
generated by the application. If the message was asyn- 
chronous, however, a control message is generated by 
conventional means in the DCC 50 to the terminal 14 to 
release control and permit subsequent data entry. 

Message passing from the DCC 50 to one of the appli- 
cation programs is conventional. Relatedly, the com- 
pound message 68 with the appended header can be 
passed directly to the application program 30, for exam- 
ple, or placed in the input message queue (IQ) 70 of the 



05/07/2003, EAST Version: 1.03.0002 



4,823, 

9 

application process 40, depending on the design of the 
XP 10. 

Refer now to FIG. 4 for an understanding of how the 
DCC 50 processes messages which arrive for the termi- 
nal 14. Output messages generated by an apphcation 5 
process for provision to the terminal 14 will have ap- 
pended by the process a copy of the header received 
with the input message being processed which caused 
the output to be generated. Thus, the SID and the MID 
described in the input process above is duplicated in the 10 
message header attached to the output message. 

It is possible that the output message is being gener- 
ated by a process that was initiated by a means other 
than the arrival of a message from a terminal such as 
reaching a particular time of day. In this case, the mes- IS 
sage is, by defmition, asynchronous and the message 
header generated contains binary zero as a message ID 
(Mir>) 82 and source ID (SID) 84. 

When an output message is generated for the terminal 
14, the message is received by the DCC 50» where a 20 
message transmission analysis routine (MTAR) 86 re- 
ceives the message and evaluates it. Evaluation is based 
on the contents of the source ID (SID) 84, the message 
ID (MID) 82, and the setting of the communication 
terminal block (CTB) message synch indicator field 25 
(SYNC-FLAG) 62. 

When the output message is received for the terminal 
14, the identifier of the terminal is used to access the 
CTB 56, The MTAR 86 inspects the CTB SYNC- 
FLAG to determine if a synchronous input message has 30 
been received and is in process. If not, any output mes- 
sage is valid for transmission to the terminal 14 and an 
output process (OP) 90 ts given control to initiate the 
transmission. 

If a synchronous output message is indicated, the 35 
source ID (SID) 84 in the message header is compared 
to the terminal ID (TID) 58 in the CTB. If they are not 
equal the output message cannot be a response to the 
message in process since it resulted from an input mes- 
sage from a different terminal. It is therefore queued for 40 
later transmission on an asynchronous output queue 
(AQ) 91. 

If the SID and TID match, the message ID (MID) 82 
in the message header is compared to the message ID 
(MID) 60 in the CTB to determine if this message is the 42 
response to the current message in process or for a prior 
asynchronous input message. If unequal, the message is 
not the proper one and is queued on the asynchronous 
message queue (AQ) 91 for later transmission. If equal, 
it is validated as the proper response and the output 50 
process (OP) 90 is given control to initiate the transmis- 
sion of the message to the terminal 14. 

When the OP 90 is dispatched, it obtains the response 
message SO and calls an output message header process- 
ing (OMHP) routine 92. The header of the output mes- 55 
sage 80 is provided to the OMHP 92. The OMHP 92 
resets the SYNCH FLAG field 62 in the CTB 56. With 
this done, the OP 90 detaches the header from the mes- 
sage, formats the message for transmission to the termi- 
nal 14, and transmits the message to the terminal 14. 60 

Now, by way of explanation of the operation of the 
above-described control blocks and modules, the syn- 
chronizing protocol of the invention is implemented 
using the procedure illustrated in FIG. 5. In FIG. 5, the 
left-hand column illustrates the process for receiving 65 
and prefixing (RCV/PFX) input messages, and is there- 
fore understood in conjunction with FIG. 3. In the 
RCV/PFX process, an input message is received from 
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the user of terminal 14, at which time the input is pro- 
cessed. This is step U. Next, in step 12. the processing 
application is determined by examination of the transac- 
tion code field 63 of the input message 52 in the routing 
module 64. Once the transaction code is determined, the 
PFX nsodule 66, in step 13, increments a message ID 
(MID) 60 value in the CTB 56 and builds the message 
prefix consisting of the Just-incremented MID value and 
the source ID (SID). The prefix is appended to the 
input message 52 in step 14. Next, in decision block IS, 
the type of processing mode is ascertained. If the pro- 
cessing mode has been determined to be synchronous, 
the PFX module 66 sets the SYNCH FLAG 62 in step 
16 in the CTB 56. If the transaction is asynchronous, the 
PFX module 66 takes no action against the CTB 56. 

Next, in step 17, the application process is scheduled 
with the operating system of the XP 10. When the appli- 
cation process executes, the input message 52 with the 
appended header is passed to the application process as 
the composite message 68. Once the application process 
is scheduled and the message is passed to the scheduled 
process, the PFX module 66 terminates the process 
according to the decision made in step 18. If the transac- 
tion mode is synchronous, the process is ended, how- 
ever the terminal 14 is "held" for the response. On the 
other hand, if the process is asynchronous, a message is 
sent by the DCC 50 to the terminal 14, freeing the ter- 
minal and imlocking its keyboard and the process is 
then ended. 

The steps of an application process with respect to 
the input message passed to it are summarized in the 
colunm of FIG. 5 under the heading APPLICATION 
PROCESS. When the application process receives the 
composite message 68, it (in step Al) determines from 
the XCODE field and any other data included in the 
message what processing is required by the indicated 
transaction. In step A2, the processing is performed, a 
result is generated, and an output message is built. In 
building the output message, the application process in 
step A3 copies the input message header to the output 
message, giving it the form indicated by reference nu- 
meral 80 in FIG. 4. In step A4, output message assem- 
bled by the application process is scheduled for submis- 
sion to the IDCC 50 for further processing. 

The process steps executed by the DCC 50 in re- 
sponse to receipt of an output message from an applica- 
tion process are summarized under the two colimuis of 
FIG. 5 headed RECEIVE OUTPUT and OUTPUT 
PROCESS, which are understood with reference also 
to FIG. 4. First, at step Ml in the RECEIVE OUTPUT 
column, when the output message 80 is received, the 
identifier of the terminal to which the message is being 
routed is used to access the CTB for that terminal. The 
MTAR 86, in step M2, inspects the CTB SYNC-FLAG 
to determine if a synchronous message has been re- 
ceived and is in process. If not, any message is valid for 
transmission and the output process is given control to 
initiate the transmission in step M3. 

In step M4, if a synchronous message is indicated, the 
source ID (SID) in the message header is compared to 
the terminal ID (TID) in the CTB. If they are not equal, 
the output message cannot be a response to the message 
in process since it resulted from an input message from 
a different terminal. It is therefore queued for later 
transmission on the asynchronous output queue in step 
M6. 

If the SID and TID match, step MS compares the 
message ID (MID) in the message header to the mes- 
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sage ID (MID) in the CTB to determine if this message process to which the message is to be forwarded. When 
is the response to the current message in process or for the message is forwarded, the field 59 is once again 
a prior asynchronous input message. If unequal, the zeroed. 

message is not the proper one and is queued in step M6 Procedures for implementing the invention are given 
on the asynchronous message queue (AQ) 91 for later 3 in Tables I, II, and HI. As will be apparent to the practi- 
transmission. If equal, it has been validated as the tionerp these are pseudo code representations which, 
proper response and the output process (OP) is given together with the accompanying description, will en- 
control to initiate the transmission in step M3. able those skilled in the art to generate, without undue 

With reference now to the OUTPUT PROCESS experimentation, the necessary machine-executable in- 
colunm of FIG. 5» assume, first, that the MTAR 86 has 10 structions to operate an asynchronous processing sys- 
dispatchcd the output process OP 90 to send a synchro- tem according to the method of the invention. In these 
nous response to the terminal 14 and that there may or tables, the right-hand reference numbers correspond to 
may not be messages in the AQ 91. First, the OP 90, in identically-labelled steps in the flow diagram of FIG, 5. 
step 01, acquires the physical output resources required 
to send the message. Next, the SYNCH FLAG «2 in the 15 
CTB 56 (step 02) is reset and the APSN 57 is set if the 
message header APSN flag is set 93. In step 03, format- 
ting of the message 80 is performed and the OP 90 
causes the message to be transmitted to the terminal 14. 
If (step 04) the output message is a synchronous tr ansae- 20 
tion response, the terminal 14 is freed by unlocking its 
keyboard in step 05. Next, the CTB APSN flag 57 is 
checked (step 07) to determine if the application pro- 
gram is maintaining synchronization. If so, asynchro- 
nous messages which are queued for delivery are not 23 
eligible for transmission so the process ends. If not set, 
the AQ 91 is inspected (step 06) to determine if asyn- 
chronous messages are available for transmission. If 
there is at least one message in the queue, the OMHP 92 
dispatches the MTAR 86, which obtains the message 30 
from the queue and follows the procedure described 
above. Each time the OMHP 92 executes, its final trans- 
action consists of an inspection of the AQ 91. When the 
AQ is emptied, the OUTPUT PROCESS is ended with- 
out a return to the RECEIVE OUTPUT process. 35 

Referring once again to FIGS. 3 and 4, the invention 
also provides a means for enabling an application pro- 
cess to maintain synchronicity with a terminal. This 
would be desirable when multiple interactions between 
the terminal and application are necessary to complete a 40 
process. In this regard, the input processing represented 
by FIG. 3 will result in the MID and SYNCH FLAG 
fields 60 and 62 of the CTB 56 being set and the message 
passed to an application process. Now, assuming the 
application process requires additional information 43 
from the terminal to complete the transaction, the out- 
put message header 80 of FIG. 4 wiU include the setting 
of an application SYNCH FLAG (APSN FLAG) field 
93. This field is set in the CTB 56 as field 59. In the 
invention, the APSN FLAG field, when serocd, indi- 50 
Gates that the application process is not maintaining 
synchronization. The MTAR 86 and OMHP 92 will 
interpret a non-zero APSN field as an indication by the 
process that synchronism is to be maintained. The value 
of the application synchronization flag field 93 will be 55 
placed in the corresponding field 59 of the CTB by the 
OMHP 92 when the message is scheduled for retrans- 
mission to the terminal 14. It is postulated that the input 
message from the terminal 14 which is responsive to an 
output message with a non-zero value in the field 93 60 
need have no transaction code. The routing module 64 
of FIG. 3 inspects the field 59 of the CTB 56 and, if the 
field is non-zero, the routing function 64 takes the action 
described above for a synchronous input message by Obviously, many modifications and variation of the 
setting the SYNCH FLAG 62, appending a header to 65 described invention are possible in light of these teach- 
the message, and putting the message ID in the MID ings. Therefore, it is understood that the invention may 
field 60, In the preferred embodiment, the field 59, if be practiced otherwise than as specifically described, 
non-zero, contains a transaction code identifying the Wc claim: 



TABLE I 


RECEIPT OF INPUT 


RECEIVE INPUT 


11 


DETERMINE SOURCE TERMINAL (LOOKUP CTB) 


11 


EXTRACT XCODE 


12 


DETERMINE APPLICATION PROCESS 


12 


INCREMENT MID-IN^B 


13 


SID = TID 


14 


HDR-MID = CTB-MID 


14 


IF APPL-CHARACTERISTIC = SYNCH THEN 


13 


SETCTB-SYNC-FLAG - ON 


16 


ELSE 




SCHEDULE APPLICATION 


17 


IF CTB-SYNC-FLAG * OFF THEN 


RS 


SEND TERMINAL UNLOCK 


R9 


ELSE 




END PROCESS 




TABLE II 


RECEIPT OF OUPUT 


LOOKUP CTB FOR OUTPUT MESSAGE 


Ml 


IF CTB-SYNC-FLAG = OFF THEN 


M2 


IF HDR-APSN-FLAO « OFF THEN 


M2 


SCHEDULE OUTPUT PROCESS 


M3 


ELSE 




ELSE 




IF CTB-TID = HDR-SID THEN 


M4 


IF CTB-MID - HDR-MID THEN 


M5 


SCHEDULE OUTPUT PROCESS 


M3 


ELSE 




ELSE 




QUEUE MESSAGE IN ASYNC QUEUE 


M6 


END PROCESS 




TABLE III 


PROCESS OUTPUT 


GET OUTPUT 


01 


FORMAT OUTPUT 


03 


SEND OUTPUT TO DESTINATION TERMINAL 


03 


IF CTB-SYNC FLAO = ON THEN 


04 


SEND UNLOCK TO TERMINAL 


OS 


ELSE 




CTB-SYNC-FLAG « OFF 


02 


CTB-APSN-FLAG - HDR-APSN-FLAG 


02 


IF HDR-APSN-FLAG = ON THEN 


07 


END PROCESS 




ELSE 




IF ASY-QUEUE =: NULL THEN 


06 


END PROCESS 




ELSE 




GO TO RECEIVE OUTPUT 
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1. A method for esublishing and maintaining conver- 
sational status, among communicating endpoints in a 
transaction processing system, said system including a 
plurality of terminals, a data communication component 
(DCC) connected to the terminals, and a transaction S 
processor (XP) for exchanging message data with the 
DCC for transmission to selected terminals, comprising 
the steps of: 

ascertaining* at the E>CC, whether a transaction initi- 
ated by a message produced at a terminal and for- 10 
warded to the XP through the DCC is synchro- 
nous or asynchronous; 

passing said transaction from the DCC to the XP for 
generation of a response; and 

processing responses to synchronous transactions in IS 
progress while buffering responses to asynchro- 
nous transactions until said responses to said syn- 
chronous transactiom are completed. 

2. The method of claim 1 wherein said processing and 
buffering step includes, for each response: 20 

identifying a terminal to which said response is to be 
transmitted; 

ascertaining whether said response has been gener- 
ated as a result of a synchronous transaction initi- 
ated by said terminal; and 25 

passing said response to said DCC for transmission to 
said terminal before transmission of another re- 
sponse to said terminal if said response has been 
generated as a result of a synchronous transaction; 
otherwise 30 

queuing said response to said DCC for transmission 
to said tenxunal after transmission of a response 
generated as a result of any in-process synchronous 
transaction. 

3. A method for synchronous transaction processing 35 
in an asynchronously-operated transaction processing 
system in which a plurality of termixuils exchange mes- 



sages with a transaction processor (XF) through a data 
communication component (DCC), said XP including 
plural application processes which support terminal- 
initiated transactions by generating responses to mes- 
sage-borne transaction codes, comprising the steps of: 
ascertaining at the DCC whether a message from a 
terminal will initiate a transaction which is syn- 
chronous or asynchronous; 
when a transaction is determined to be synchronous, 
executing against a data object associated with said 
terminal to provide an indication in said data object 
of said synchronous transaction; 
passing messages received from said terminal to the 

XP from the DCC for initiating transactions; 
generating responses for said transactions in the XP; 
and 

in reaction to each response generated for said termi- 
nal by the XP; 

examining said data object to ascertain whether a 
synchronous transaction has been initiated; and 

if a synchronous transaction has been initiated, 
transmitting only a response included in said 
synchronous transaction to said terminal, and 
buffering all other responses for transmission to 
said terminal until said synchronous transaction 
is completed; otherwise 

transmitting said responses to said terminal. 

4. The method of claim 3, wherein said buffering 
includes placing said other responses in an asynchro- 
nous message queue. 

5. The method of claim 4 further including, after 
transmitting any response, inspecting said asynchronous 
message queue and, if said asynchronous message queue 
contains at least one response, dequeuing and transmit- 
ting a response from said asynchronous message queue. 
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